Location- and temporal-based services for nature-society interaction regulation

concise and intensional periodic time expressions (Carnap 1947) instead of their extensional counterparts. This point gains in importance with the expansion of mobile and ubiquitous systems, which leads to an increased volume of such space and time located queries. Of course, information about local time and space can directly be captured from the mobile device, which places the call. Moreover, an abstract – say object – model embedding intensional temporal expressions is a very convenient frame for ensuring interoperability, especially with applications in charge of displaying the retrieved information (e.g., maps) on Smartphones. Another application field refers to simulation framework based on located multiagent systems (MAS) (Weiss 2000; Shoham and Leyton-Brown 2009). Users are no longer human agents, but state machines. The system consists of a Knowledge Base (KB), and located clients query the KB so as to determine their behaviour at runtime. In this case, it is usual to deal with discrete systems and asynchronous agents, making it cumbersome if not intractable to store calendar datetimes with multiple contexts and granularities. Additionally, recording, but datetime occurrences hides a lot of semantic issues, namely about periodicity. In this paper, we provide a generic UML (Unified Modelling Language 1 ) Class model (OMG 2009) for specifying temporal knowledge. UML is a specification language for modelling objects. The ISO 19100 series standard 2 , we will reference below, is specified with UML (ISO/TC211 2010). Moreover, we reused types of time characterized in (Isard 1970) like: linear time, cyclic time, ordinal time, and time as distance. Our approach keeps close to the natural language and to the domain/business model. However, one important point is that, in contrast with natural languages, our specification language is unambiguous. Our contribution must be seen as a forehand basic step towards any of the four main threads in the Visual Analytics Agenda (Thomas et al. 2005; Andrienko et al. 2007). In fact, the common pivot UML model allows designing interoperable applications in the fields of analytical reasoning, visual representation and user interaction, data transformation via Model Driven Engineering (MDE) (Bézivin 2005; Schmidt 2006), and production/dissemination. Moreover, it leverages the operational bridging of these threads to one another. As regards the paper organization, the next Section elicits our contribution to the Visual Analytics Agenda. Then, Section 3 is dedicated to presenting the example applied to professional seashell digging; it shows that coping with temporal expressions is mandatory at various stages, and suggests in which ways these expressions can be exploited. Section 4 presents excerpts of the object model, which are central parts of our proposal. Section 5 evokes how the underlying Smartphone applications and the multiagent system interact with the Temporal Model. We conclude by listing the key issues of our work and outline the future developments. 2. Interaction with the Visual Analytics Agenda Our work has been initialized and deliberately achieved within a wide general application context, yet we intend to outline below why it can fruitfully and specifically apply to visual analytics. Let us adopt the classification of the R&D Agenda and successively address its four identified threads (Thomas et al. 2005). As regards analytic reasoning, either human or software agents need to access prior asserted pieces of information before processing logical or empirical reasoning and inference, and possibly contribute to decision making. Whatever the goal: assessment, forecasting or developing and testing options, these agents must browse and select relevant information and data. The object model we have designed provides a context-independent way to depict the domain temporal knowledge. As a pivot model, it also provides a seamless access to various knowledge and data warehouses, whichever the language in use (SQL, RDF, XML). It is also beneficial when willing to integrate temporal and spatial knowledge. The last thread is also directly concerned by these facilities: within a dissemination process, the requirements remain the same as above, but in that case, the display of results targets end users instead of intermediate agents. Likewise, the pivot model can help bridging the domain temporal knowledge to computer-mediated representation frameworks that bear human interactions and tease intuition. In fact, it provides a set of classes and methods that directly interoperate with visualization API specifications. This is a significant contribution to the visualization and interaction techniques. With regard to the third thread, model driven engineering allow customized data transformation based on model mapping. So as to apply these most effective techniques, having a consensual shared domain model at one‟s disposal is mandatory. Here, the temporal object model allows to transform model elements as well as data instances from any modelling space (source) into any other (target). For instance, via a common intermediate object representation, data from XML and RDF resources can be integrated so as to feed widgets Class instances in a visualization application. In all the cases above, the pivot model allows to leverage software design and data integration, by means of interoperability, reusability, maintainability and ease of verification and validation. 3. The Telline (Donax Trunculsus) use case This section presents a use case dedicated to providing time specification facilities for the modelling of marine fishing activities. The final goal is to provide the user with a language that handles a large set of abstract temporal expressions, in particular periodic (cyclic) ones (e.g., “each first Wednesday in the month”). More precisely, the example simulates the professional Telline (Donax trunculus, edible saltwater clam) digging process in Douarnenez bay 3 (France). Telline digging appeared during the 1970‟s in Douarnenez and proved to be highly profitable, what led to a rapid Telline‟s stock exhaustion (Guillou 1982). In order to achieve a sustainable regulation of the activity, the administration drafted orders for ruling the access to fishing areas, by restricting the digging duration and imposing a feedback about captures. This use case reveals the actual complexity of the digging activity calendar and requires a specification on how multi-scaled spatio-temporal constraints on this activity can impact the resource stock. 3.1 Activity temporal modelling Temporal modelling consists of building a Temporal Potential Practice (TPP), which results from compiling various constraints (see Figure 1):  For each registered digging field, the law specifies „allowed‟, „restricted‟ or „prohibited‟ digging periods.  Sea state and tide, as well as temperature, constrain the accessibility to digging areas.  The bacteriological quality of water also has an impact on fishing rights. All of these constraints are related to several periodical factors. With regards to the registered digging field of Douarnenez-Camaret, in addition to other constraints („Weather condition‟, „Tidal coefficient‟ and „Sale price‟), it is stipulated that: “digging is prohibited each year, from 9 p.m. to 6 a.m. between July 1 st and August 31 st . Out of these periods, digging is allowed from 3 hours before low tide up to 3 hours after the same low tide (according to the tide almanac in Douarnenez). Otherwise, it is restricted”. This rule is depicted on the TPP in Figure 1, by the first constraint time-zones named „Regulation‟. Figure 1 uses a time wheel representation (Peuquet 2002; Moellering 1976; Edsall and Sidney 2005) to show periodical properties like regulation and tide indicator. The tide period is „12h50‟ and for other constraints the cycle is annual. The time wheel corresponds to a homogeneous area as regards the various parameters. It accounts for a set of mean conditions computed over several consecutive years and provides a mean pattern for the parameters that impact on Telline seashell digging. Local conditions possibly add some corrections to the mean effect. Figure 1. Temporal Potential Practice for Donax trunculus digging. Specifying and setting the multiagent behaviour requires that temporal knowledge and databases be queried at runtime in order to update the modelled environment, agent states, and interactions. This is a complex issue, since all basic temporal rules must be coded as well as their exceptions, including relative time positions of events (weather, oceanography, administrative decisions, etc). Dealing here with time occurrence semantics is much better than dealing with time occurrence data. 3.2 Activity spatial modelling Spatial analysis methods permit the building of a Spatial Potential Practice (SPP) for the activity. The SPP results from the superimposition of geographical information layers that account for the set of geographical constraints upon the activity. With regards to Donax trunculus, the SPP consists of the registered digging areas boundaries, the bathymetry, the sedimentary nature of the intertidal zone, and also of the digging areas accessibility (paths, roads, docks, etc). All constraints are likely to evolve either in a deterministic, stochastic (predictable – e.g., environment change) or chaotic way (unpredictable – e.g., pollution accident). Managing these evolutions (effects) implies that the source events calendar (causes) is managed accordingly. Due to the marine environment complexity, a minimum amount of information has been defined for running the simulation process. In particular, the physical characteristics of the environment (such as bathymetry, submarine geomorphology, tides and weather conditions) and the activity regulatory constraints are required. The constraints that impact on the spatial development activities are specific to each activity. They tally with thematic layers formatted in a Geographic Information Base (GIB) processed by GIS. GIS spatial analysis functions are used to superimpose the various GIB layers on a single layer finally accounting for all of the practice conditions. This analysis layer contains a set of polygons, which specify whether the modelled activity is likely to be developed or not, and thus describes the SPP. 4. Periodical (cyclical) Phenomenon Modelling We propose a general UML object model for specifying temporal events properties i.e., the Temporal Occurrence Model. Many instances of this model are taken into consideration within the process. More precisely, there is one special instance for each pair of (activity, location). Periodic characteristics are based on such temporal basic concepts as Instant and Period as well as on secondary concepts with their related properties, which can be found in several well known standards such as iCalendar (Dawson and Stenerson 1998) or OWL-Time (W3C 2006). 4.1 Motivations for creating a Domain Specific Language for temporal expressions Time can be considered from many viewpoints: mathematics, philosophy, economics, meteorology, etc. Our motivation is to design a language, which can help specifying non ambiguous models likely to be easily understood and managed by human beings, and also to be processed efficiently by computers. So, we accompany our model with a textual grammar (see Subsection 4.8), which is close to the natural language. The model is designed to apply to a very wide scope. The object model can capture both concrete (extensive set of calendar dates) and comprehensive time expressions (abstract specification of a set of periodic/cyclic occurrences). We do not address signal processing (Fourier transform), even if we eventually do split complex time properties of events into a set of simple ones. Instead, we intend to keep close to natural languages. One of our goals is to provide a means to compute and reason about temporal occurrences initially extracted from textual (English, French) specifications (Faucher et al. 2010). Standards like the ISO 19108 (ISO 2002) or iCalendar still have some lacks with regards to our requirements. In fact, both periodical restriction on existing periodical rule and relative positions between occurrences need to be handled. With respect to interoperability among the various applications (e.g.: Smartphones, MAS, knowledge base query engine, GIS access, etc) we rely upon Model Driven Engineering techniques, which is a most convenient paradigm for achieving the implementation of the required models and data transformers. 4.2 Temporal Occurrence Model basics We selected the ISO 19108 standard as a reference for modelling the basic concepts: Instant and Period. The main reasons for this choice are the following:  The object representation of the ISO 19108 proves to be well suited for being used with MDE as a pivot representation between software applications that have to deal with the various technical spaces (Bézivin 2005) in use.  The ISO 19100 series treats of geographical information issues that are commonly associated with temporal features.  Having a pivot object model at one‟s disposal leverages the mapping of temporal concepts in hand with items from other application and domain oriented time specification languages. o Namely OWL-Time for specifying an ontology including time issues, for expressing logical time rules and for performing formal reasoning about time properties. o SQL-Time for relational database querying, according to time constraints. iCalendar for scheduling applications that deal with both periodic and non periodic event occurrences. 4.3 Periodic Rule Model Within the scope of the present paper, and for the sake of brevity, we only discuss selected excerpts of our model 4 . Let us first focus on the central concept in Figure 2. The PeriodicRule class is the root element of our model for defining periodicity issues about a PeriodicTemporalOccurrence. A PeriodicTemporalOccurrence is a set of PeriodicRules. Each aggregated element indicates a simple periodic phenomenon (i.e., only one Frequency). The composition of all elements in the set results in the sum of the simple periodic components. Consequently, the first property of a PeriodicRule is its Frequency. According to a common definition (DiBiase et al. 1992), a Frequency is a pair of values respectively indicating the number of occurrences (times attribute) that happen during a given time span (referenceDuration role). As shown in Figure 2, referenceDuration ends in a Duration data type. This might be too restrictive in practice, since only durations can then be referenced. Thus, in our proposal, we give access to the whole set of AbsoluteTemporalExpressions for specifying the start and the end of the desired interval. Intrinsic periodic CalendarPeriodicDescriptors can be specified as discussed in Subsection 4.4 via the role periodicTimeInterval (e.g., “each Monday”, “each first Tuesday”). A PeriodicRule owns an optional ruleExtent that defines the interval during which the rule is valid. This property is needed when checking if a concrete date is consistent with the given rule or not. The optional startTime attribute is specified for one frequency, in order to anchor the first periodic phenomenon occurrence on a concrete calendar i.e., to define its phase once its frequency is known. As mentioned above, if no referenceDuration is given for a PeriodicRule, then a PeriodicTimeInterval must be specified with two properties, namely begin and end, which are AbsoluteTemporalExpression (see Subsection 4.4). Of course, constraints are to be checked e.g., begin precedes end for all occurrences, and both begin and end should have the same frequency, but begin and end occurrences may present a phase difference. This means that the length of PeriodicTimeInterval occurrences are not necessarily equal to one another (e.g., PeriodicTimeInterval occurring “from the first Tuesday to the last Monday of each month”). The class PeriodicRelativePosition is used to specify a PeriodicInstant in relation with one previously defined (see Subsection 4.6). Figure 2. Excerpt of the Periodic Temporal Occurrence model. 4.4 Calendar Periodic Descriptor The model excerpt shown in Figure 3 provides means for specifying the major calendar units when dealing with time issues. Figure 3. Excerpt of the Calendar Periodic Descriptor model. Calendar units actually are abstractions that implicitly account for the essential periodic nature of calendar items, hence the name of the root class: CalendarPeriodicDescriptor. The Instant/Period duality clearly appears here as an artifact of the granularity. One can either specify: “the event takes place in May” or “the event occurs between May 1 st and May 31 st ”. Even though the two assertions have equivalent semantics; they effectively refer to different underlying concepts. When the Instant viewpoint prevails, days in a week and months in a year are identified by their name (Monday, March, etc). On the contrary, week, month and year rather refer to a sliding period with a more or less precise duration: week is a period of 7 days, month a period of 28/.../31days, and so on. Instants may also be specified by adding a NumericRank to a calendar unit e.g., “3 rd Sunday, 28 th week”. Adding a rank to a calendar item changes the viewpoint to this item. In fact, as mentioned above, month refers to a sliding period, while “3 month” refers to the third month in the year and is actually a synonym of March, which indicates an instant. This also applies to unlabeled units such as: the “2 nd week” of a month or the “2 nd week” of a year. 4.5 Rule Extent and Periodic Time Span A periodic phenomenon is basically infinite. For practical use, time boundaries should be provided, at least for identifying the starting point. The ruleExtent role specifies the period during which the PeriodicRule applies. The association end is a TM_Period with a beginning and an optional end. It is not required that the boundaries correspond to exact occurrences. The semantics of ruleExtent is that all occurrences are valid inside the extent and invalid otherwise. A fixed time extent may prove insufficient to capture some situations, which are not scarce among periodic events. As a matter of fact, the extent should itself often be periodic. This, for instance is the case in the following assertion: “the event occurs each first week of the month from March to September” (see Figure 4). Therefore, a PeriodicTimeSpan is defined to specify a periodic time restriction: “from March to September”, which occurs each year. An additional ruleExtent could assert that the rule applies for example from 2010 to 2015. The PeriodicTimeSpan is expressed as a special PeriodicTimeInterval. For sake of simplicity, no inner PeriodicTimeSpan should be nested in a primary one. Figure 4. Periodic Rule with a Periodic Time Span in practice. 4.6 Relative Temporal Occurrence TopologicalPrimitive is provided by the ISO 19108 in order to capture the pairwise relationship between primitives. We added the concept of FeatureRelativePosition (see Figure 5) to provide facilities for specifying the sets of occurrences of temporal objects in relation to one another. Therefore, it is possible to specify relative positions between periodic expressions such as “3 hours before low tide”. This expression is periodic time interval “each first week of the month”